Noah, Thanks for making things clear, I've nothing to add and I see the plan. I'm +1 to your proposal. -- ,,,^..^,,,
On Fri, Jul 5, 2013 at 5:20 PM, Noah Slater <[email protected]> wrote: > Thanks for your mail, Alex! You raise some great points. > > On 4 July 2013 19:58, Alexander Shorin <[email protected]> wrote: > >> At the moment of release point master's features might not be actually >> ready for release due to lack of testing, docs or something. > > > This is why I am hoping someone can really take ownership of the Git > workflow stuff and drive it to conclusion. Because one of the things we > want to introduce is that you do not merge to master until there are tests, > docs, etc. In fact, merges to master are done via lazy consensus on the > list. So we will all get a chance to object to something landing. > > Ok, not good example, but I think idea is clear: make release >> because time is over and feature is not fixed is not good. >> > > These features should be done in branches. Things should only land on > master when they are complete, with tests, and docs. > > >> I fear that it would be very easy to run into version racing while >> nothing interesting these release will provides. If we aims to provide >> something new with each release, probably better to drop patch version >> number at all. >> > > We're not aiming to do anything other than ship what is ready, on a regular > basis. And that means that our releases will become smaller, and > more manageable. And this will be a good thing overall. > > >> Another problem that it would be easily to make 2-3-4 major releases >> every 4 weeks just because they are ready - this brings compatibility >> hell and users will reasonable to ask "why I have to use latest >> version when they breaking things every month? I'll better stay on 1.3 >> - it's stable enough and fulfils my remeasurement". >> > > Not necessarily. We really shouldn't be making breaking changes every > month. We should be planning them as a team and landing them in batches, > spaced out, so as not to tax the community. Nothing about the release > procedure I have proposed changes that, or makes it any harder to do. > > >> But what's the git workflow for such schedule? I see very seductive >> reason to commit all to master to have this time based releases really >> featured and look not so bad while been compared with 1.2 and 1.3 >> (just take a look one more time on their release notes). >> > > I see what you're saying, but I don't think anybody feels this pressure. In > fact, part of the goal here is to make the releases smaller and > more manageable Though, I have to say, if this spurs people on to get > features ready and to merge them in to master, then that sounds awesome to > me. > > Of course, I wouldn't want things being merged in that weren't ready, but > as I mention, all merges to master should be done with a lazy consensus > thread posted to dev@, that details what the feature is, what tests there > are, and what the docs are like. This is your chance to object, if the > feature is only half baked, or needs to be held back. > > >> I think this schedule need to be heavy integrated with git workflow. >> For instance, the rule (see [DISCUSS] Git workflow thread): >> >> > Master is always releasable. All work occurs on feature or fix >> > branches and is merged to master only after tests confirm that it >> > works. >> >> will help a lot to solve problems above. After 4 weeks when time is >> over, RM requests for list of all feature-fix branches that are ready >> for merge, merging, one week for final testing (might not be always >> required, but still this option requires to be announced) and then cut >> the new release bumping version number in right way (major, minor or >> patch). >> > > There's no reason to batch that merges for the last week. The merges should > be happening as and when they are ready. In fact, I would be quite > concerned that if we held them all back until the week before the last > release, we are introducing a bottleneck. Also consider that we are a > volunteer organisation, and so people are free for this sort of activity as > an when their lives permit. It's not something we can reliably hope to > schedule for a single week. > > On other hand, I agree that features shouldn't wait a years for the >> release and releases might be a bit often, but I also think that this >> process should be described in details to solve edge cases. >> > > There's no way we can exhaustively document the whole thing up front. Well, > we could, but I think we'd find that it doesn't match reality. What we > should be aiming for is iterative understanding and improvement of the > process. > > >> P.S. No offence, just a thoughts (: >> > > No offence taken at all. Thank you for your constructive email. > > I think that if you consider the proposed Git workflow, then most of your > concerns (which are entirely valid) become non-issues. And I'm interested > to here if you think that is the case also. > > I will take this opportunity to plead with the community again: we need > somebody to take ownership of the Git workflow stuff, to look over the > discussion, figure out a single proposal, and bring it to the community for > a quick vote. > > I want to switch to this master branch based release process, and it very > much relies on "no merges to master until the feature is complete with > tests and docs" part of the proposal, so we need to make official as soon > as possible! > > -- > NS
