Branched for release
Just a heads up for people that we've branched for release and that jethro branches are now available. Bitbake branched as 1.28, I decided to save bitbake 2.0 for another occasion.
These branches are going to track master for a while yet as we stabilise the release.
Cheers,
Richard
Quoted 3 lines · Richard Purdie
Just a heads up for people that we've branched for release and that jethro branches are now available. Bitbake branched as 1.28, I decided to save bitbake 2.0 for another occasion.
what would be the occasion ?
this time lets branch consistently. Across different repositories please. I would also suggest to not use codenames in branches but rather the numbered release. If we want to use codenames for branches then lets drop the numbered release names.
Quoted 17 lines
These branches are going to track master for a while yet as we stabilise the release.
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 11 lines · Khem Raj
Quoted 3 lines · Richard Purdie
Just a heads up for people that we've branched for release and that jethro branches are now available. Bitbake branched as 1.28, I decided to save bitbake 2.0 for another occasion.
what would be the occasion ?
this time lets branch consistently. Across different repositories please. I would also suggest to not use codenames in branches but rather the numbered release. If we want to use codenames for branches then lets drop the numbered release names.
I agree.
The mix between codenames and version numbers cause a lot of confusion for outsiders. We, involved with the project development can handle it (even though sometimes I ask myself if one codename is older or newer than another) but for outsiders it is deadly confusing.
Signature · 3 lines
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
Quoted 6 lines · Otavio Salvador
I agree.
The mix between codenames and version numbers cause a lot of confusion for outsiders. We, involved with the project development can handle it (even though sometimes I ask myself if one codename is older or newer than another) but for outsiders it is deadly confusing.
As I've just replied to Khem, I posted a fairly comprehensive look at all the possible options quite a while back, the last time people complained. Basically, we can't win. We have slowly killed off all the numbers that didn't have a purpose so we have one naming scheme and one number that corresponds to it.
The only real exception is bitbake, which as tool with its own release/versions, makes sense.
I'd also highlight that now is not the time to start changing the release process.
Cheers,
Richard
Quoted 4 lines · Khem Raj
I would also suggest to not use codenames in branches but rather the numbered release. If we want to use codenames for branches then lets drop the numbered release names.
I suggest using both (codename+release_number).
Ex: jethro-2.0 or 2.0-jethro
(probably the later one is better as it can be sorted by release number easily)
That way everyone has clear which release number and which codename is, without having to fire a browser to
https://wiki.yoctoproject.org/wiki/Releases
Quoted 8 lines · Carlos Alberto Lopez Perez
Quoted 4 lines · Khem Raj
I would also suggest to not use codenames in branches but rather the numbered release. If we want to use codenames for branches then lets drop the numbered release names.
I suggest using both (codename+release_number).
It would be good to have simple and revealing names like release-X.Y or branch-point-X.Y for tags etc.
And this would also then benefit rest of projects under YP umbrella if they were to use same release numbering.
OE is a bit unique then other distribution frameworks in regards that the user has to interact with sources since
its source based unlike other distro's like fedora and debian-like which are binary feed based for most of users
and a small subset deals with the build metadata repositories. So it would help the community at large if there
was simple naming conventions.
Quoted 17 lines
Ex: jethro-2.0 or 2.0-jethro
(probably the later one is better as it can be sorted by release number easily)
That way everyone has clear which release number and which codename is, without having to fire a browser to
https://wiki.yoctoproject.org/wiki/Releases--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 7 lines · Khem Raj
Quoted 3 lines · Richard Purdie
Just a heads up for people that we've branched for release and that jethro branches are now available. Bitbake branched as 1.28, I decided to save bitbake 2.0 for another occasion.
what would be the occasion ?
Memory resident Bitbake? Toaster developments? Logging improvements? New shell commands?
Quoted 2 lines
this time lets branch consistently. Across different repositories please.
Bitbake is the only repo which doesn't use the branch codename. I did write at length about how version numbers as branches would actually cause much more pain than any problem they solve, bitbake is one of the few exceptions to that given its a tool, not metadata and has a more consistent history where the version number means something specific and is actively used.
Quoted 3 lines
I would also suggest to not use codenames in branches
but rather the numbered release. If we want to use codenames for branches then lets drop the numbered release names.
The number does have some uses, its really not that simple.
If we want to discuss this all again, so be it, but on the eve of release really isn't the time to start it all again.
Cheers,
Richard
Quoted 6 lines · Richard Purdie
Quoted 2 lines · Khem Raj
On Thu, Oct 1, 2015 at 7:24 AM, Richard Purdie
<[email protected]> wrote:
Quoted 9 lines
Quoted 5 lines
Quoted 3 lines
Just a heads up for people that we've branched for release and that jethro branches are now available. Bitbake branched as 1.28, I decided to save bitbake 2.0 for another occasion.
what would be the occasion ?
Memory resident Bitbake? Toaster developments? Logging improvements? New shell commands?
bitbake is tied ot OE metadata, even though its a separate repository, it can be viewed as any other metadata layer.Moreover I don’t know if there are any other projects besides OE using it. All above look good features but not clear whats there relation to bumping major release number. Do they make 1.9 incompatible in some different ways than that we don’t do between 1.x releases ?
Quoted 10 lines
Quoted 2 lines
this time lets branch consistently. Across different repositories please.
Bitbake is the only repo which doesn't use the branch codename. I did write at length about how version numbers as branches would actually cause much more pain than any problem they solve, bitbake is one of the few exceptions to that given its a tool, not metadata and has a more consistent history where the version number means something specific and is actively used.
Quoted 6 lines
Quoted 3 lines
I would also suggest to not use codenames in branches
but rather the numbered release. If we want to use codenames for branches then lets drop the numbered release names.The number does have some uses, its really not that simple.
They do tell me the chronology of releases I get that but then I don’t understand why can’t be use it in name for branching then, why does it have to be no relation between branch and release names ?
I am not sure if you are aware enough of the confusion it causes to new users, not all distros use combo layer like tools to fudge the layer identities and create a new repositories where this can be less of the problem since the new repository could have its own versioning scheme.
Quoted 2 lines
If we want to discuss this all again, so be it, but on the eve of release really isn't the time to start it all again.
so when is the right time ? Do we have long enough pre-notice about when we the branching is going to happen?
Quoted 5 lines
Cheers,
Richard
Quoted 5 lines · Khem Raj
Quoted 2 lines
If we want to discuss this all again, so be it, but on the eve of release really isn't the time to start it all again.
so when is the right time ? Do we have long enough pre-notice about when we the branching is going to happen?
We release approximately in April and October with a six month cadence.
After the complaints about communication, there have been weekly status updates and the release dates were also *clearly* shown in there for when the release was planned. Incidentally, if those aren't useful, Stephen and I can stop doing them.
Its not unreasonable to assume the branch for release happens sometime before the first rc build of the release.
Cheers,
Richard
Quoted 5 lines · Richard Purdie
Quoted 2 lines
so when is the right time ? Do we have long enough pre-notice about when we the branching is going to happen?
We release approximately in April and October with a six month cadence.
Quoted 7 lines
After the complaints about communication, there have been weekly status updates and the release dates were also *clearly* shown in there for when the release was planned. Incidentally, if those aren't useful, Stephen and I can stop doing them.
Its not unreasonable to assume the branch for release happens sometime before the first rc build of the release.
treat this as discussion for next release, since enough water has passed to make it for this one. I will open a bug in yocto tracker as well as a reminder
Quoted 12 lines · Khem Raj
Quoted 10 lines · Richard Purdie
Quoted 2 lines
so when is the right time ? Do we have long enough pre-notice about when we the branching is going to happen?
We release approximately in April and October with a six month cadence.
After the complaints about communication, there have been weekly status updates and the release dates were also *clearly* shown in there for when the release was planned. Incidentally, if those aren't useful, Stephen and I can stop doing them.
Quoted 6 lines
Quoted 2 lines
Its not unreasonable to assume the branch for release happens sometime before the first rc build of the release.
treat this as discussion for next release, since enough water has passed to make it for this one. I will open a bug in yocto tracker as well as a reminder
I have opened a tracker for 2.1 in bugzilla for this
https://bugzilla.yoctoproject.org/show_bug.cgi?id=8432
everyone please feel free to record your inputs to this ticket.
Quoted 9 lines · Richard Purdie
Quoted 5 lines · Khem Raj
Quoted 2 lines
If we want to discuss this all again, so be it, but on the eve of release really isn't the time to start it all again.
so when is the right time ? Do we have long enough pre-notice about when we the branching is going to happen?
We release approximately in April and October with a six month cadence.
Quoted 7 lines
After the complaints about communication, there have been weekly status updates and the release dates were also *clearly* shown in there for when the release was planned. Incidentally, if those aren't useful, Stephen and I can stop doing them.
Its not unreasonable to assume the branch for release happens sometime before the first rc build of the release.
I think what Khem means is that any time is time to discuss the release process as this is a community driven project and we must to be open for feedback and revisit our previous concepts.
I agree with Khem concerns here and I also believe we should rethink the versioning / branching schema.
Signature · 3 lines
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
Quoted 3 lines · Otavio Salvador
I think what Khem means is that any time is time to discuss the release process as this is a community driven project and we must to be open for feedback and revisit our previous concepts.
There is a time and a place for such discussions. I think its clear that right now, I'm personally finding the situation we're in rather stressful and even getting the release into a shape where it can ship is proving difficult.
The last thing I need right now is to go through this discussion again. Particularly when people have not gone and read the things I wrote up last time this was discussed. I could ask why not, the answer is probably because its easier just to ask questions and be unhappy with what we have.
I appreciate that what we have today does cause some issues. I also realised a while ago that regardless of what solution we pick, there are people who are not going to like it. I've talked about that in previous mailing list posts to try and explain why we end up where we are today. I also don't believe anything has materially changed since we last discussed this, some people are just still unhappy. Some people will be unhappy regardless.
I'm actually at a pretty low point with OE and Yocto in general. It eats up a huge amount of my time, both work and personally and I have started wondering what I actually get out of it other than a shortened life expectancy. On the most part I see a lot of complaints about things and continual questioning of "why we do X and wouldn't Y be better". I do my best to deal with this patiently and each time try and explain why and then re-evaluate if a change makes sense or not. When the same things repeat time and again, my patience can wear thin though.
Now, I do realise that there probably are some happy users out there and that happier users tend to be quieter than the unhappy ones, at least I certainly hope so. As such, I tend to see the worst side of the projects all the time. Equally, it can get to you after a while.
So, yes, I do believe there is a time and place for discussions and not everything should be questioned and discussed at any time. That doesn't mean its not a community driven project.
Anyhow, I can't stop any discussion, however my point is I'd much prefer to spend my time trying to sort out the release. If others feel differently, I will indeed have to spend more time on this instead. I do also believe it is too late to change things for this release[1].
[1] Since I will no doubt get asked to explain that, the consequences are quite significant when you consider bugzilla version fields, autobuilder scripts, release scripts, my own branching scripts and so on. The things I haven't thought of worry me even more. Yes, we can in theory change anything and we could change this, but its probably a week of work shaking out just those changes. Do I want to do that now? No, I don't. For example I'm attending ELC-E next week. Do we want me talking to people or sitting in a corner trying to un-break such a change?
Cheers,
Richard
Quoted 25 lines · Richard Purdie
Quoted 3 lines · Otavio Salvador
I think what Khem means is that any time is time to discuss the release process as this is a community driven project and we must to be open for feedback and revisit our previous concepts.
There is a time and a place for such discussions. I think its clear that right now, I'm personally finding the situation we're in rather stressful and even getting the release into a shape where it can ship is proving difficult.
The last thing I need right now is to go through this discussion again. Particularly when people have not gone and read the things I wrote up last time this was discussed. I could ask why not, the answer is probably because its easier just to ask questions and be unhappy with what we have.
I appreciate that what we have today does cause some issues. I also realised a while ago that regardless of what solution we pick, there are people who are not going to like it. I've talked about that in previous mailing list posts to try and explain why we end up where we are today. I also don't believe anything has materially changed since we last discussed this, some people are just still unhappy. Some people will be unhappy regardless.
Quoted 8 lines
I'm actually at a pretty low point with OE and Yocto in general. It eats up a huge amount of my time, both work and personally and I have started wondering what I actually get out of it other than a shortened life expectancy. On the most part I see a lot of complaints about things and continual questioning of "why we do X and wouldn't Y be better". I do my best to deal with this patiently and each time try and explain why and then re-evaluate if a change makes sense or not. When the same things repeat time and again, my patience can wear thin though.
believe me you are doing a fine job :) infact I recognise that maintainership is a thankless job.
Quoted 6 lines
Now, I do realise that there probably are some happy users out there and that happier users tend to be quieter than the unhappy ones, at least I certainly hope so. As such, I tend to see the worst side of the projects all the time. Equally, it can get to you after a while.
No silence does not mean happiness and similarity bringing up issues does not mean unhappiness, On the contrary It is that I am being caring enough to help projects adoption in the areas where people havent heard the name of OE, so its a different perspective and vouch for the issues that gets a headwind in adoption.
Quoted 9 lines
So, yes, I do believe there is a time and place for discussions and not everything should be questioned and discussed at any time. That doesn't mean its not a community driven project.
Anyhow, I can't stop any discussion, however my point is I'd much prefer to spend my time trying to sort out the release. If others feel differently, I will indeed have to spend more time on this instead. I do also believe it is too late to change things for this release[1].
Quoted 9 lines
[1] Since I will no doubt get asked to explain that, the consequences are quite significant when you consider bugzilla version fields, autobuilder scripts, release scripts, my own branching scripts and so on. The things I haven't thought of worry me even more. Yes, we can in theory change anything and we could change this, but its probably a week of work shaking out just those changes. Do I want to do that now? No, I don't. For example I'm attending ELC-E next week. Do we want me talking to people or sitting in a corner trying to un-break such a change?
I think you are right about timing. But on and off this discussion has come up and incidentally its always during release
I guess because we all try to consume the changes and it comes to fore anyhow I have opened a tracker bug to follow it up. Let everyone record the
inputs there, so it can be then considered for next release.
Quoted 5 lines
Cheers,
Richard